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2 Overview 



Hie HAVi Architecture specifics a set of Application Protn-amming Interfaces (APIs) allowing 
consumer electronics manufacturers and 3 rd parties to develop applications for the home network, 
llius the home network is viewed as a distributed computing platform, and the primary goal or the 
HAVi Architecture is to assure that products from different vendors can interoperale - i.e.. can 
cooperate to perform application tasks. 

To explain fully the interoperability aspects or die arcliitecture. it is necessary that we begin with an 
overview of home networking and identify the requirements addressed by the HAVi Architecture. 
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2»1 The Home Network 

Current CE devices, such as DVD players and DV camcorders, are sophisticated digital processing 
and digital storage systems. By connecting these devices in networks, it is possible to share 
processing and storage resources - Uiis allows new applications that: 

coordinate the control of several CE devices simultaneously, and 
; ; ; simplify operation of devices by the user. 

For instance one device may initiate recording on a second wliile accessing EPG information on a 
third The home network provides the fabric for connecting CE devices. It allows connected 
devices to exchange both control information (one device sending a command to another) and AV 
content (one device sending an audio or video stream to another). To be successful in the consumer 
electronics domain the home network must meet several requirements. These include: timely 
transfer of high- data -rate AV streams, self-configuration and self-management, hot plug-and-play. 
and low-cost cabling and interfaces. The HAVi Architecture is intended for networks based on the 
IEEE 1 394 standard 1 394 is a powerful technology that meets many of the requirements ot home 
networks. An example of a 1 394 network is shown below: 
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Hie underlying structure for the home network coasists of set of interconnected clusters or devices 
I ypically. there will he several clusters in the home, with one per noor. or per rami, liach cluster 
will w( T k as a set ol interconnected devices to provide services to users. Ollen one device will 
control other devices. However, the HAVi Architecture is sufficiently llexihle to allow home 
networks with no single master control device. 

2.2 Requirements 

The HAVi Architecture is an open, light-weight. platliKm-independent and architecturally neutral 
spccil.cauon that allows consumer electronics manufacturers develop interoperable devices and 
independent application developers to write applicatioas for these devices. It can be implemented 
on dilierent hardware/software platforms and d<x-s not include features that are unique to any one 
platform. 

The interoperability interfaces of the HAVi Architecture are exteasible and can be advanced as 
market requirements and technology change. They provide the infrastructure to control the routine 
and processing ot isochronous and ume-seasitive data such as audio and video content. 

2.2.1 Legacy Devices Supported 

The HAVi Architecture supports legacy devices, i.e. devices that already exist and are available to 
users. ITus is important since the transition to networked devices is going to be gradual - with 
manufacturers not suddenly producing only networked devices and coasumers not quickJy 
replacing their existing devices. 

Legacy devices can also be characterized by the degree to which they support 1 394 and industry 
standard protocols for 1 394 such as EC 6 1 S8 3. In particular we can divide legacy devices into the 
following categories: 

non- 1 394 devices 

1 394 devices not supporting the HAVi Architecture 

Most existing CR devices fall into the first category, while existing devices with 1394 interfaces tall 
into the second category. 

HAVi-compliant devices, as opposed to legacy devices, are those that support the HAVi 
Architecture. The various categories of HAVi-compliant devices are described in section 2.3.3. 

2.2.2 Future-Proof Support 

The CI- industry has great concern that new products work with existing products. While currently 
mis is largely question of media formats and interconnect standards, die HAVi Architecture 
supports future devices and protocols through several M ,lt ware-based meclianis.as. These include: 

* Pt-TS'sient device-resident information describi ng capabilities of devices 

s a write-once, run-everywhere language called HA Vi hyweode 



L-vice independent representation of user interface elements 
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Kach HAVi-compIiant device may contain persistent data concerning its user interface and device 
control capabilities. ITiis information can include HAVi bytecode that can be uploaded and 
executed by other devices on the home network. As manufacturers introduce new models with new 
features they can modify the bytecode shipped with tlie device. The new functionality added to the 
bytecode mirrors the new features provided by the device. Similarly new user interface elements 
can be added to the stored Ul representation on the device. 

2.2.3 Plug-and-Play Support 

Home network consumer devices are easy to install, and provide a significant portion of their value 
to the consumer without any action on the user s part, beyond physically connecting the cables. 
This is in distinction to existing devices that require configuration to provide some major portion of 
their functionality. Home networking technology offers "hot" plug-and-play (not requiring the user 
to switch off devices), and safe and reliable connections. 

In the HAVi Architecture, a device configures itself, and integrates itself into the home network, 
without user interventioa Low-level communication services provide notification when a new 
device is identified on the network. 

While there will often be settings the user may change to suit his or her preferences, the HAVi 
Architecture does not require the user to perform any additional installation operations (as 
compared to installation for non-net worked or stand-alone usage). Frequently, installing a device on 
the home network will be simpler than stand-alone installation since new devices can obtain 
configuration information from those already on the network. Thus the infamous "Hashing clock on 
the VCR" can be solved by having the VCR set its clock to that of another device on the network - 
for example a DTV receiving time signals via digital broadcast. 

2.2.4 Flexible 

The HAVi Architecture allows devices to present multiple user interfaces, adapting to both the 
user's needs and the manufacturer's need for brand differentiation. The architecture includes a 
flexible device model that scales gracefully from simple CK devices like a CD player or audit) 
amplifier to res<xirce-rich. intelligent devices such as DTV receivers. 

2.3 System Model 
2.3.1 Control Model 

The home network is coasidered to consist of a set of AV devices. P'ach device lias, as a minimum, 
enough functionality to allow it to communicate with other devices in the system. Hie one 
exception to this are legacy devices (see section 2.3.3). 

During the course of interaction, devices may exchange control and data in a peer-to-peer fashion. 
This ensures that, at die communication level, no one device is required to act as a master or 
controller for the system. However, it also allows a logical master or controller to impose a control 
structure on the basic peer-to-peer communication model. 

The HAVi control model makes a distinction between controllers and controlled devices. A 
controller is a device that acts as a host for a controlled device. A controlled device and its 
controller may reside on the same physical device or on separate devices. 
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.h^T ' u^ , HAVi ^ nlr< " m)dCl 3 a,ntr,,,lcr is S3id '° ,M *« a ^•'^ Cmtral Model (KM) for 
the controlled dcv.ee. rhe control interface is exposed via the API of this IX'M 'Ihis API is the 
only access point lor applications to control the device. 

!ml^^r, intd ' ig ? '? CVisi0n ^ ,ami ' y r<X>m "^ht * ^ w,nlr(l|ltr f«r a number ol ■ 

Zr^T t Z'l' SUCh 3 COntr0llCd dCViCCS COuld con,ajn H A Vi b > 1 ^' iha' constructs a 
user .mer ace lor the device and allows external control of the device. When these devices are first 

connected the controller obtains the user interlace and control code. An icon representing £ 

dev.ee may then appear on the television screen, and manipulating the icon may cau.se elements ol 

the control program to actuate the represented device or devices ir, prescribed ways. 

11* home network allows a single device, or a group of devices communicating amongst 
themselves to deliver a service to a user or an application. When it is necessary for a device to 

(possibly the device in question or possibly a dif ferent device). 

2.3.2 Device Model 

A distinction is made between devices Afunctional components. A good example of this 
disuncuon can be found in a normal TV set. Although the TV set is generally one physical box it 

^JZSLT? C ** ^ 3Udi ° ^ «<■ SSStXSk 

device are called funcuonal components. 

2.3.3 Device Classification 

(wS^^ TI^ Cate S lTies: Fu " A V devices (FAV). Intermediate A V devices 
IAV) Base AV devices (BAV) and Ugacy AV devices (LAV). HAVi-com P Uant devices are 
those m the first three categories, all other CE devices Tall into the fourth category. 

2.3.3.1 Full AV Devices 

A Fuu AV device contains a complete set of the software elements comprising the H A Vi 
^octuic (see section 2.4.4). This type of device generally has a rich set o. resources and is 

F/fv^,h .n PP ° rt,ng r COmP ' CX SOftwan: cnvir< ^ nment - ^ primary distinguishing feature of a 

. r P C !! CC ° 3 mnlimC envir <— 1 H A Vi bytecode. I rus allows an FAV to upload 
bytecode from oth<* devices and so provide enhanced capabilities for their control. Likely 
candidates (or IAV devices would be Set Top Boxes (STB), Digital TV receivers (DTV) general 
purpose home control devices, and even Home PC's. 

2.3.3.2 Intermediate A V Devices 

r^!^^ V . dCViCCS ^ genCra " y l0WCT in COSI than FA V dcvi «* and limited in 
res<Kirces. They do not provide a runtime environment lor HAVi bytecode and so can not act as 
conu-ollers tor arbitrary devices within the home network. However an IAV may prSe ntive 
support lor control of particular devices on the home network. 

2.3.3.3 Base A V Devices 

These are devices that, for business or resource reasons, choose to implement lutiire-proof behavior 
Arcrutetturc. I riese devices can be controlled by an FAV device via the uploadable bytecode or 
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from an IAV device via native axle, lhe protocol between the BAV and its controller may or may 
not he proprietary. Communication between a Full or Intermediate AV device and a BAV device 
requires that HAVi commands be traaslated to and from the command proaxol used by the BAV 
device. 

2.3.3.4 Legacy A V Devices 

LAV -devices arc devices that were built before the advent of the HAVi Architecture. These devices 
use proprietary protocols lor their control, and quite frequently have simple control-only protocols. 
Such devices can work in the home network but require that FAV or IAV devices act as a gateway. 
Communication between a Full or Intermediate AV device and legacy device requires that HAVi 
commands be translated to and from the legacy command protocol. 



Services in the HAVi Architecture are modeled as objects. Each object is a self-contained entity, 
called a software element, accessible through a well-defined interface and executing within a 
software execution environment hosted by the device on which the object ruas. Note that different 
devices may host different execution environments. Services are accessed, using the 
communications infrastructure, via their well-defined interfaces. 

Services in the HAVi Architecture can be provided by device manufacturers, or can be added.by 3 rd 
party vendors. The software model makes no distinction between "standard" services and vendor 
services; they are both implemented as objects, 

2.4.2 Software Element Identifiers 

Lach object is uniquely named No distinction is made between objects used to build system 
services and those used for application services. All objects make themselves known via a system 
wide naming service known as the registry. 

Objects in the system can query the registry to find other objects and can use the result of that query 
to send messages to those objects. 

The identifier assigned to an object is created by the messaging system before an object registers. 
These identifiers are referred to as SFIDs - Software Element Identifiers. SFIIDs are guaranteed to 
be unique, however the SKID assigned to an object may change as a result of reconfiguration of the 
home network (i.e.. device plug-in or plug-out). 

2.4.3 Message-Based Communication 

All objects communicate using a message passing model. Any object that wishes to use the service 
of another object does so by using a general purpose message passing mechanism that delivers the 
service request to the target object. The target object is specified using the unique SKID discussed 
above. 

This general purpose message passing mechanism abstracts from the details of physical location, 
i.e. there is no distinction between an object on the same device and one on a remote device. Tlx.* 
actual implementation ot the message passing infrastructure will differ from device to device and 



2-4 HAVi Software Architecture 



2.4.1 Object-Based 
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between vendors. However, die format of HAVi messages, and the protocol used for their delivery 
must be common so that interoperability is assured. ^-"very. 

^L g ^ Ta ' '.TH ° • • >bJtX ' 1 '"^ and mcssa ^ n S system is to provide a completely generic 
oS S^l M SUl ,toihfc to al,ow multi P'^ implementauoas w7h a vitey of 

*em at S ^ angUagt f- ,)C,ailS ° flhe bindi " g bCtWCcn mcssa ^ and thai handles 

tnem are left to the system implement! >r. 

2-4.4 Software Elements 

The software dements of the HAVi Architecture support the basic notions of network 
^gemeni device absuactioa inter-device communication, and device UI management 

J T C C,CmCmS CXFX1KC "* '^P^iliry API. a set of serv ices for building 
portable distributed apphcahoas on the home network, The software elements themselves reside 
above a vend., specillc platform such as a RTOS. TUc diagram below depicts ^ ngemtm of 
fr^'?^ k AV dCViCe ' Whi, ° nW tatendotl ™ an i-piementa P uon b.uepr"t Z 

« a^s , c HA , Vi so,twarc demcnLS rorm a ^ ,a ^ ^ p ,a «<™ 

spouiic APIs and platform independent applications. 



Interoperability API 




The software elements comprising the HAVi Architecture and defined in this specification are: 

m itV Co " ,mmication Media Manager - allows other elements to perform asynchronous 
. and isochronous communication over 1 394. ^ynenronous 



ments. 



m Meting System - responsible for passing messages between ele 

* E l ent Meager - serves as an event delivery service. An event is the chance in state of an 
object or of the home network. fc C °' an 

* Stream Manager - responsible for managing real-time transfer of A V and other media 
between functional components. d 
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Registry - serves as a directory service, allows any object to locate another object on the 
home network. 

Device Control Module (DCM) - a software element used to control a device. DCMs are 
obtained from DCM code units. Within a DCM code unit are code for die DCM itself plus 
axle for Functional Component Modules (FCMs) for each functional component within 
device. In addition a DCM code unit may include a device control application - a 
software element allowing user control of the device and its functional components. 

DCM Manager - responsible for installing and removing DCM code units on FAV and 
IAV devices. 

DCMs are a central concept to the HAVi architecture and the source of llexibility in accorruxlaling 
new devices and features. DCMs come in two main types: 

embedded DCM - a DCM pre-installed on IAV and possibly FAV devices. 

uploaded DCM - a DCM implemented in HAVi bytecodc. Uploaded DCMs only run on 
F AV devices. 

DCMs can provide APIs for control of both families of devices and specific models. Generally the 
former APIs will have a wider range of usage, but the latter allow control of vendor-specific 
features and capabilities. 

In addition to the above software elements specified by the HAVi Architecture, devices on the 
home network may contain the following: 

HAVi Self Describing Device (SDD) data - HAVi-compliant devices contain descriptive 
information about the device and its capabilities. This information, called HAVi SDD 
data, follows the IEEE 1212 addressing scheme used for Configuration ROM. The HAVi 
SDD data may include a DCM code unit and data for constructing user interface 
elements. 

HAVi Bytecode Runtime - provides a runtime environment for uploaded DCMs (or 
applications) implemented using HAVi bytecode. 

DDI Controller - a native or bytecode entity involved with user interaction. The DDI 
(Data Driven Interaction) Controller handles user input and interprets DDI elements. 

The following table summarizes which architectural elements are present for the various device 
categories, which are absent and which are optional. A "check mark" indicates that the element is 
present on the device itself with the following provisions: 

For both BAV and LAV devices there must be an associated device control module 
somewhere on the home network. For a BAV device, the DCM is obtained via the 
device's HAVi SDD data. For LAV devices, the DCM would be pre-installed on the 
controlling FAV or IAV. 

For IAV and FAV devices it is not necessary that a DCM exists on the home network. 
(However, if such a DCM does not exist then interoperable applications cannot control 
the device.) 
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Device Type / Element 


FAV 


IAV BAV LAV 


HAVi Bytecode Runtime 


✓ 




Stream Manager 


✓ 


[✓J 


001 Controller 


[V] 




OCM Manager 


✓ 


✓ 


Registry 


✓ 


✓ 


Event Manager 


✓ 


✓ 


Messaging System 


✓ 


✓ 


1394 Communication Media Manager ✓ 


✓ 


HAVi SOD data 


✓ 




OCM 







2.5 User Interface Support 

The primary goal of the user interlace of the home network is to offer a comfortable oneratino 
environment to users. The HAVi Architecture allows users to control dcvS»S«SS2 
mean, such as v,a the from pane, or via the buttons ofa remote controller. In adS HAVi 
Architecture allows device manufacturers to specify graphical user interfaces (GU IsTwhTch can be 
rendered on a range of displays varying from text-only to high-level graphical disDlavs^ Trie GIJI 
TsTJZZ^r * * ^ - Mother device a^d T3S£££ 

^ m0lh ? manutaaurer - T » Powerlu. feature, the HAVi 

Architecture mtroducos a mechanism called Data Driven Interaction (DDI), m essence HAVi 

DD ^ T ,nC ^ D ° l e,em ~ a P ' atf0rm '"indent encoding o user inu^facc^ements 
DW e ements can be loaded and displayed by a DDI controller. The DDI controller^eSev^l 
DDI elements vna the DCM (rather than directly from the SDD data, so it is pcSEte Z ^KM 
..sell ,s the source of DDI elements). The DDI Controller generates HAVi J^m ta^irSi 
user tnput. ,, also responds to events generated by the DCM as a result C21n de 
rhis communication is called the DDI protocol. ^ c Mah " 

It should he emphasized that the DDI Controller does not understand what happens as a result of 
= ga contro, message. So it is possible to handle new functioas which cSSl *,? 

This DDI Controller can not provide guarantees over the graphical rendition of DDI elements since 

sszrrr may * changed ^ ,o ,ack ° r ™*™ - ™* - 

? iV nh f n 2 re ' a PP^o" software can create different representations usine the DDI 

TZT a V hinLS ) HOWeVCT ^ DDI C ° ntroUcr *** ^ «« P^crv'the appease of DDI 
elements subject to its rendering capabilities. 

2.5.1 Layout Mechanism 

Layout rules of DDI elements are based on geometric ccx^dina.es and use x. y value, for each DDI 
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clement. DIM elements are arranged in a hierarchy and positioned relative to their parents. 

The target device suggests a preferred layout, which is encoded into die DDI data structure. 
However, Hie DDI Controller may tailor the presentation of DDI elements based on its own 
limilatioas. such as screen size, ability to display graphics or text only. etc. 



2.5.2 Navigation Mechanism 

The navigation between DDI elements is liandled locally by the DDI Controller. The target device 
may suggest navigation rules between certain DDI elements. Because such navigation rules are just 
suggestions, the controller may tailor the navigation of the display based on its adjustment of DDI 
layout. 



2.6 Home Network Configurations 

The HAVi Architecture defines the way devices are abstracted within the home network and 
establishes a framework for device control. It defines the ways that interoperability is assured, and it 
defines the ways that future devices and services can be integrated into the architecture. The HAVi 
Architecture makes no restrictions, however, on what types of devices must be present in the home 
network. As a result several configurations are possible - networks without FAV devices, networks 
with multiple FAV devices, networks with LAV and B AV devices only, etc. Depending upon the 
types ol devices on the home network, several different operational configurations are possible. 



2.6.1 LAV and BAV Only 

The HAVi Architecture does not provide any support for networks consisting of only BAV and 
LAV devices. However with the addition of a HAVi controller (an IAV or FAV) to the network, 
these devices can be made available to applications. 

2.6.2 IAV or FAV as Controller 

IAV and LAV devices act as controllers for the other device types and provide a platform for the 
system services comprising the HAVi Architecture. To achieve this FAVs provide a runtime 
environment'for HAVi bytecode DCMs, while I AVs may host embedded DCMs. From an 
interoperability perspective, the primary role of a controller is to manage DCMs and provide a 
runtime environment for DCMs. AppLicatioas use the APIs provided by the DCM to access the 
controlled device. 



IAV or FAV 



IAV or FAV 



LAV or BAV 




IAV or FAV aa controller 
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2.6.3 IAV or FAV as Display 

Generally. IAVs and FAVs will have an associated display device that is used for display of AV 
content and GUIs. However, the architecture does not mandate this and an IAV or FAV device 
may he "headless" (without display capahiUty). In this case they will miperaie with tuner IAV or 
KAV devices with display capability. Such devices will typically support a DDI Controller 
Propnetary low-level graphic manipulation APIs can he used by the DDI Controller to access the 
display itsell. hut these interlaces are not exposed as part of the Interoperability APIs 



display 



IAV or FAV 



IAV or FAV 



LAV or BAV 



001 
Controller 



I 



001 
protocol 



display 
device 



DCU 



I 



proprietary 



controller 



controlled 
device 



IAV or FAV as display device 



2.6.4 Peer-to-Peer Architecture between FAVs and IAVs 

In a home network, there may be more than one FAV or more than one IAV In this case each 
controller^! A V or FAV) cooperates with other controllers to ensure that services are provided to 

S^wIS , ° W f ^"J? rESOUrCCS - exam P ,e is dcSCTibed in 2.6.3 where a 

device without display capabilities uses a remote device to display DCM user interfaces A more 

elaborate example could be an FAV device utilizing the services of a data translation module 
located on a remote device to set up a data stream between two A V devices. 

2.6.5 IAV as Controller and Display 

A home network may contain no FAV devices, in such cases IAVs are the only entities which mav 
control other dev^es. Although not equipped with a rumirne environment for uploaded DCMs an 
IA V may be shipped with a set of embedded DCMs. 1 -Imbedded DCMs can be implemented as 
native applications on the IAV device and can use native interfaces to access the IAVs display and 

H AVi^chTi ^ UkC ,)CMS in gCncraK in r W Provided by the 

H A V, Architecture and can be accessed from other devices on the home network by sending 

DnTnr^vT mCSSagin « Wan. Fmbcdded DCMs. lite DCMs in general, may support the 
DDI protocol and so may participate in providing a user interface for the controlled device. 

2.7 Interoperability in the HAVi Architecture 

e^in^n?^° rCm ? t / 0al ° f ^ HAVi ArcW, « aure is «» S "PP^ interoperability between AV 
equipment. This includes exasung equipment and future equipment. Because of the need to suddoti 
cx 1S ung devices, and because of product cost considerate the HAVi ArcMc^^^^ 
levels of interoperability. We refer to these as level 1 and level 2 respectively. 
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The flexibility of choosing different levels ol interoperability is essential in allowing vendors the 
freedom to design and build devices at all points on the cost/capability spectrum. 

2.7.1 Level 1 Interoperability 

Level I interoperability addresses the general need to allow existing devices to communicate. To 
achieve this, level I interoperability defines and uses: 

a generic set of control messages (commands) thai enable one device to talk to another 
device and 

a set of event messages that it should reasonably expect from the device. 
To support this approach a basic set of mechanisms are required. 

Device discovery: each device in the home network needs a well-defined method that 
allows it to advertise its capabilities to others. The approach the H AVi Architecture has 
adopted is to utilize H AVi SDD data, required on all FAV, IAV and BAV devices. SDD 
data contains information about the device which can be accessed by other devices. The 
H AVi SDD data contains, as a minimum, enough information to allow instantiation of an 
embedded DCM. This results in registration of device capabilities with the HAVi registry, 
allowing applications to infer the basic set of command messages that can be sent to the 
device. 

Communication: once an application has determined the capabilities of another device, 
then it needs to be able to access those capabilities. To achieve this requires a general 
communication facility allowing applications to issue requests to devices. This service is 
provided the HAVi messaging systems and DCMs. The application sends HAVi 
messages to DCMs, the DCM then engages in proprietary communication with the 
device. 

HAVi message sets: the last mechanism required to support level l interoperability is a 
well defined set of messages that must be supported by all devices of a particular class. 
This ensures that a device can work with existing as well as future devices, irrespective of 
the manufacturer. 

These three basic requirements support a minimal level of interoperability. Since any device can 
query the capabilities of another via the registry, any device can determine the message set 
supported by another device. Since applications have access to the messaging system, then any 
device can interact with any other device. 

2.7.2 Level 2 Interoperability 

Level l interoperability ensures that devices can interoperate at a basic level of functionality. 
However, a more extensible mechanism is also needed to allow a device to communicate to other 
devices any additional functionality not present in embedded DCMs. For example, embedded 
DCMs may not support all features of existing products and are unlikely to support future product 
categories. I^vcl 2 interoperability provides this mechanism. 

To achieve this, the HAVi Architecture allows uploaded DCMs as an alternative to embedded 
DCMs. The uploaded DCM may replace an existing L)CM on FAV devices. The HAVi 
Architecture makes no statement about the source of the uploaded DCM. but a likely technique is 
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o place the uploaded DCM in the HAVi SOD data or the B AV device, and upload from the B A V 
to the IAV device when the BAV is attached to the home network. Because the HAVi Architecture 
is vend(r neutral, it is necessary that tlx; uploaded DCM will work on a variety of FA V devices all 
with fxHentiaUy different hardware architectures. To achieve this, uploaded DCMs are implemented 
in HAVi bytecode. I he HAVi bytecode runUme environment on I- AV devices suppons the 
iastanliation and execution of uploaded DCMs. 

Once created and running within a FAV device, the DCM communicates with the I.AV and BAV 
devices in the same manner as described above in section 2.7. 1 

IT* efficiency of level 2 interoperability appears when one coasiders resources needed to access 
device functionality. I^vel 2 allows a device to be controlled via an uploaded DCM that presents 
all (he capabilities offered by the device. Whereas to achieve similar functionality in level 1 this' 
DCM would have to be embedded somewhere in the network. For example when a new device is 
added to a network, level 1 requires that at least one other device contains a IXJM suitable for the 
new device. Incomparisoa level 2 only requires that one device provide a runtime environment for 
the uploaded DCM obtained from the new device. 

The concept of uploading and executing bytecode also provides the possibility for device specific 
apphcauons called Device Control Applications. By these applications a device manufacturer can 
provide the user a way to control special features of a device without the need lor standardizing all 
the features in HAVi. The application is provided by a DCM in HAVi bytecode and can be 
uploaded an installed by each FAV device on the network. 



2.8 Versioning 

Kach HAVi component must support the HAVi version control API. HAVi version control is 
intended to maintain interoperability of HAVi components as the specification evolves Version 
control lor individual manufacrurer's products is outside of the scope of this API. 

Versions are represented by major and minor numbers in the form M i or .mir-r For a given 

release ot the specification, all components will be of the same version as that of the HAVi 

specification - regardless of whether that component's API was modified in the latest release This 

simplifies the situation in which a given component s APIs are built up from different groups of ' 

APIs. The minor version number is intended indicate small refinements or the HAVi specification 

'" tc ™ °J r ^ t™)™ version nun *er is to reflect important functional improvements in the 
overall HAVi architecture. 

Given that this draft specification is Version 0.8. all HAVi components are currently defined to be- 
at Version 0.8. It ,s intended that no APIs will be changed or removed as the draft specification 
evolves, though this is not absolutely guaranteed. Updates to existing APIs will he generally be 
achieved by adding new APIs. (e.g. if int g.tFoo < ) changes during the evolution of the draft 
specihcatioa int g«tFooA ; , may be added to the API. and the original i n t a ^F- •■ •• will not 
be removed.) 111 n " 1 

At the first official release of the specification, all components will be of Version 1 .0. At this time 
all deprecated APIs will be removed from the specification, and the updated APIs will be renamed, 
(int. g*tFooA<) would be renamed in;. ff «:Foo<) and the older int oecFoofi API would 
be removed). 

As the official release of the specification evolves, it is intended to no APIs will ever be updated or 
removed. All changes will be achieved by adding new APIs. This easures that older components 
can always request services from newer components successfully. 
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Before a component requests a service, il must ilrst check the version of the component which is to 
provide that service. If the version of the component providing the service is greater than the 
version of the component which is requesting the service, the requesting component must 
communicate with the service provider using the requestor's most current APIs. 

If, on the other hand the requestor finds that ti>e service provider is of an older version, the 
requestor must restrict itself to APIs that are known to be supported hy the older component. A 
minimum requirement is that the requestor must he able to interact with older providers using 
protocols from all major releases of the specification older than the requesting component. As an 
example, if Component A3 3 is of Version 3.3. Component B24 is of Version 2.4 and Component 
C 1 2 is at Version 1.2, A3 3 is required to communicate with B24 using APIs of Version 2.0 at a 
minimum. When A33 or B24 communicate with component CI 2. the minimum AIM version is 1.0. 
Ihe manufacturer may also choose to differentiate between Versions 2. 1 . 2.2, 2.3 and 2.44in the 
case of A3 3 requesting a service from B24). but litis is optional. 

The rules for version control of message passing protocols is somewhat different. Please refer to the 
Message Passing section for details. 

Applications are encouraged to support older component versions, though this is not explicitly 
required. 'litis is intended to ensure that interoperability will be achieved for the life of the H AVi 
specification. 
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